密码套件的定义与作用
密码套件是 TLS 连接的”算法配方”——它是一个由 IANA 官方编号(如 0xC02B)注册的标识符,完整定义了 TLS 连接中使用的四类密码学算法的组合。
在 TLS 握手阶段,客户端在 ClientHello 中发出一组候选密码套件,服务器在 ServerHello 中选中一个。一旦选定,整个 TLS 会话的:
- 密钥交换方式
- 服务器身份认证方式
- 应用数据加密方式
- 密钥派生函数
全部由这个密码套件决定,会话中不可更改。
密码套件名称的四段式结构
以使用的 ECDHE-ECDSA-AES128-GCM-SHA256 (0xC02B) 为例,名称从左到右分为四段:
ECDHE — ECDSA — AES128 — GCM — SHA256 |
- ECDHE 是一次性的:密钥交换只发生在握手阶段一次,后续数据传输不再使用
- ECDSA 是验证性的:仅用于验证服务器身份,不参与后续数据加密
- SHA256 是持续性的:从握手到会话结束,贯穿密钥派生和完整性校验(Finish时计算sha256得到verify_data)
- AES128-GCM 是全程性的:ChangeCipherSpec 之后,所有应用数据的加解密全程使用(用于对TLS 记录层的载体部分加密/解密)
时间轴 ──────────────────────────────────────────────────────────────────► |
密钥交换算法:ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)
| 项目 | 说明 |
|---|---|
| 作用 | 协商会话密钥(预主密钥 pre-master secret),不直接传输密钥 |
| 安全属性 | 提供前向保密(Forward Secrecy):即使服务器长期私钥泄露,历史会话仍安全 |
| 分类 | 属于 DHE 家族(临时 DH),对比 DH-RSA(无前向保密) |
| 对比 | RSA(无前向保密,服务器直接用 RSA 加密 pre-master secret 发回)、DHE(基于有限域,非椭圆曲线) |
代码体现
// generateECDHEKeyPair 根据指定曲线生成 ECDHE 密钥对 |
// computeSharedSecretECDH 根据指定曲线计算 ECDHE 共享密钥 |
签名算法:ECDSA(Elliptic Curve Digital Signature Algorithm)
| 项目 | 说明 |
|---|---|
| 作用 | 服务器在 ServerKeyExchange 中对密钥交换参数签名,证明”我持有对应证书的私钥” |
| 对比 | RSA(用 RSA 私钥签名)、DSA(已淘汰) |
| 与证书的关系 | 服务器证书必须包含匹配类型的公钥(ECDSA 证书 ↔ ECDSA 签名) |
| 注意 | ECDSA ≠ ECDH:ECDSA 用于签名验证身份,ECDHE 用于密钥协商。两者用同一条椭圆曲线但功能不同 |
加密算法+密钥长度+加密模式:AES128-GCM
这一部分实际包含两个子字段:
加密算法+密钥长度:AES128
- AES(Advanced Encryption Standard)
- 密钥长度:128 位 = 16 字节
- 对比 AES256(256 位 = 32 字节):安全强度更高,但性能略差
加密模式:GCM(Galois/Counter Mode)
- AEAD 模式(Authenticated Encryption with Associated Data)
- 同时提供机密性(加密)和完整性(认证标签)
- 对比:
CBC(仅机密性,需额外 HMAC 做完整性校验,已被淘汰) - 对比:
CCM(另一种 AEAD,需要计数器模式 + CBC-MAC,性能略差)
| 项目 | 说明 |
|---|---|
| 作用 | 加密和解密 TLS 应用数据(HTTP 请求/响应) |
| 密钥长度影响 | 直接决定派生密钥的长度 → keyLen = 16(AES-128)或 keyLen = 32(AES-256) |
|
哈希函数:SHA256
| 项目 | 说明 |
|---|---|
| 作用 1 | TLS PRF(伪随机函数)的底层哈希 → 派生主密钥和会话密钥 |
| 作用 2 | Finished 消息中对所有握手消息的完整性哈希 |
| 作用 3 | 扩展主密钥(Extended Master Secret)的哈希运算 |
| 对比 | SHA384(输出更长,安全强度更高,与 AES-256 配对) |
常见密码套件对比
| 密码套件 | 编号 | 密钥交换 | 签名 | 加密 | 哈希 | 备注 |
|---|---|---|---|---|---|---|
ECDHE-ECDSA-AES128-GCM-SHA256 |
0xC02B | ECDHE | ECDSA | AES-128-GCM | SHA-256 | 推荐:现代主流 |
ECDHE-ECDSA-AES256-GCM-SHA384 |
0xC02C | ECDHE | ECDSA | AES-256-GCM | SHA-384 | 高强度 |
ECDHE-RSA-AES128-GCM-SHA256 |
0xC02F | ECDHE | RSA | AES-128-GCM | SHA-256 | 兼容 RSA 证书 |
ECDHE-RSA-AES256-GCM-SHA384 |
0xC030 | ECDHE | RSA | AES-256-GCM | SHA-384 | 兼容 RSA 证书 + 高强度 |
AES128-GCM-SHA256(无 ECDHE) |
0x9C | RSA | RSA | AES-128-GCM | SHA-256 | 无前向保密 |
ECDHE-ECDSA-AES128-SHA |
0xC009 | ECDHE | ECDSA | AES-128-CBC | SHA-256 | 已过时:CBC + HMAC |
全强度对齐原则
密码套件的选择遵循安全强度对齐原则——各组件的安全强度应处于同一等级:
| 安全等级 | 椭圆曲线 | AES | 哈希 | 典型套件 |
|---|---|---|---|---|
| ~128 位 | secp256r1 / X25519 | AES-128 | SHA-256 | 0xC02B |
| ~192 位 | secp384r1 | AES-192 | SHA-384 | 0xC02D |
| ~256 位 | secp521r1 | AES-256 | SHA-512 | 0xC02E |
0xC02B + secp256r1 正是 128 位安全等级的完美对齐组合,是当前 TLS 1.2 中使用最广泛、安全与性能平衡最优的现代密码套件。
为什么选择 ECDHE-ECDSA-AES128-GCM-SHA256 + secp256r1
安全强度匹配
这是一组安全强度对齐的经典搭配:
| 组件 | 安全强度 | 说明 |
|---|---|---|
| secp256r1 (P-256) | ~128 位 | 基于椭圆曲线的对数难题,256 位参数 ≈ 128 位安全 |
| AES-128-GCM | 128 位 | 对称加密密钥长度 128 位 |
| SHA-256 | 256 位 | 哈希输出 256 位 |
| ECDSA | ~128 位 | 基于 secp256r1 曲线的签名 |
如果选择了 secp256r1(128 位安全)+ AES-256(256 位安全),就是安全强度不对称——椭圆曲线才是瓶颈,AES-256 的额外强度是浪费。反之,如果选择 secp384r1(192 位安全)+ AES-128(128 位),就成了加密算法的瓶颈。
兼容性与现代性
- secp256r1 (NIST P-256):FIPS 标准、广泛支持、
crypto/ecdh原生支持 - AES-128-GCM:当前主流的认证加密算法,性能优秀
- ECDHE:提供前向保密(Forward Secrecy)
- ECDSA 证书:现代网站越来越普遍采用
对比其他可能的组合
| 组合 | 问题 |
|---|---|
| X25519 + 0xC02B | 0xC02B 与 X25519 通常不配对,传统上 secp256r1 配 ECDSA 证书 |
| secp384r1 + 0xC02B | 安全强度不匹配,且 P-384 性能较差 |
| secp256r1 + ECDHE-RSA 套件 | 服务器用 RSA 证书,与 ECDSA 曲线不匹配 |
密码套件 (Cipher Suite) 与椭圆曲线的关系
密码套件是一个”算法组合包”
ECDHE-ECDSA-AES128-GCM-SHA256 (0xC02B) 是一个 TLS 密码套件,它规定了 TLS 连接使用的四个核心算法:
| 套件组件 | 含义 | 代码中的体现 |
|---|---|---|
| ECDHE | 密钥交换算法:使用椭圆曲线 Diffie-Hellman 临时密钥交换 | 由 skxCurve 决定具体曲线 |
| ECDSA | 服务器证书签名算法:服务器用 ECDSA 验证身份 | 从证书公钥类型自动判断 |
| AES128-GCM | 会话数据加密算法 | encryptGCM / decryptGCM |
| SHA256 | 密钥派生和消息认证的哈希算法 | tls_PRF_SHA256 |
椭圆曲线是密钥交换的”具体实现参数”
密码套件只说了”用 ECDHE 做密钥交换”,但没有说”在 哪条曲线 上做 ECDHE”。椭圆曲线(如 secp256r1、X25519)就是 ECDHE 的底层数学基础——它决定了密钥交换在哪个椭圆曲线群上进行。
两者的关系图
TLS 连接安全 |
简单说:密码套件决定”用什么种类的算法”,椭圆曲线决定”用哪条具体的曲线”。
密码套件 规定了 TLS 的”整体算法配方”(密钥交换种类 + 加密算法 + 哈希算法),
椭圆曲线 规定了 ECDHE 密钥交换”在哪条曲线上进行”。
二者是正交维度的选择:套件是”用 ECDHE 做交换”,曲线是”在 secp256r1 上做”。
选择 0xC02B + secp256r1 是因为它们在安全强度上完美对齐(都提供 ~128 位安全),且是 TLS 1.2 中最主流、兼容性最好的现代组合。
ECDHE-ECDSA-AES128-GCM-SHA256 各组件的作用时机详解
总体流程图
┌─────────────────────────────────────────────────────────────────────────────────┐ |
各组件的详细作用时机
ECDHE — 密钥交换算法(步骤 ⑥ 及密钥派生阶段)
何时起效:握手中期,在服务器消息全部接收完毕后(步骤 ⑥~密钥派生)
具体做什么:
| 阶段 | 操作 |
|---|---|
| 准备 | 客户端在 ClientHello 中声明支持 ECDHE(通过密码套件 0xC02B 和扩展) |
| 服务器发起 | 服务器在 ServerKeyExchange 中发送其 ECDHE 公钥 + 签名 |
| 客户端生成 | 客户端生成自己的临时 ECDHE 密钥对 |
| 客户端发送 | 客户端将 ECDHE 公钥封装在 ClientKeyExchange 中发给服务器 |
| 计算共享密钥 | 客户端用自己的私钥 × 服务器的公钥,在 secp256r1 曲线上计算共享密钥 |
核心价值:共享密钥永不在线传输,双方各自用私钥×对方公钥得出同一结果。即使日后服务器私钥泄露,历史会话仍安全——这就是前向保密。
客户端: priv_client × pub_server = shared_secret ┐ |
ECDSA — 签名算法(步骤 ④)
何时起效:服务器证书验证 + ServerKeyExchange 签名验证
具体做什么:
| 阶段 | 操作 |
|---|---|
| 证书解析 | 从 Certificate 中解析服务器公钥,确定为 ECDSA 类型 |
| 签名验证 | 服务器对 ServerKeyExchange 内容(随机数+曲线+公钥)做 ECDSA 签名,客户端验证 |
核心价值:证明”公钥交换参数确实由持有证书私钥的一方发出”,防止中间人攻击者替换 ECDHE 公钥。
ServerKeyExchange 内容: |
SHA256 — 哈希函数(密钥派生阶段 + Finished)
何时起效:密钥派生和完整性校验
具体做什么:
| 用途 | 操作 |
|---|---|
| 密钥派生 PRF | master_secret = PRF(sharedSecret, "master secret", clientRand+serverRand) 用 SHA-256 做 HMAC |
| 密钥派生 PRF | key_block = PRF(masterSecret, "key expansion", serverRand+clientRand) 派生 4 个密钥/IV |
| Finished 哈希 | hsHash = SHA256(所有握手消息) 用于 Finished 完整性校验 |
| Finished PRF | verifyData = PRF(masterSecret, "client finished", hsHash) 产生 12 字节验证数据 |
| ServerKeyExchange 签名哈希 | hashBytes = SHA256(verifyData) 作为 ECDSA 签名输入 |
核心价值:SHA-256 是 TLS 内部的”粘合剂”——密钥派生靠它、握手完整性校验靠它、签名哈希也靠它。
密钥派生链 (全部基于 SHA-256 PRF): |
AES128-GCM — 加密算法(步骤 ⑧ 及之后全程)
何时起效:ChangeCipherSpec 之后的所有消息(Finished + 应用数据)
具体做什么:
| 阶段 | 操作 |
|---|---|
| 激活 | ChangeCipherSpec 通知双方后续使用新密钥加密 |
| 首次使用 | 客户端 Finished 消息用 AES-128-GCM 加密发送 |
| 应用数据加密 | encryptGCM(plaintext, key, iv, seq, type) 加密 HTTP 请求/响应 |
| 应用数据解密 | decryptGCM(ciphertext, key, iv, seq, type) 解密 HTTP 响应 |
核心价值:GCM 同时提供机密性(AES 加密)和完整性(16 字节认证标签),一次运算完成两个目标。
AES-128-GCM 加密过程: |